7章 空の道具箱

私はこのような投資の欠如を空の道具箱と呼んでいます。

「投資の欠如」……まさに。プロダクトを作ることばかり注力すると、プロダクト以外のところに負債が蓄積するのですね。

システム全体を考えなければなりません。人・サポートシステム・データベースサーバ・ネットワークは、すべてソリューションの一部です。

DevOps の根本だ。

システム全体が自動化を念頭に置いて設計されていないと、システムのさまざまな部分で自動化の欠如が生じます

これめっちゃわかる。。。インフラとテストと運用の最低限の自動化は本当に必要。

運用とは、プロダクトを構築し維持するために必要なすべてのタスクや活動のことです。たとえば、サーバの監視・テストパイプラインの管理・ローカル開発環境の構築などが挙げられます。これらはすべて、ビジネスに価値を与えるために必要な作業です。

ほんとそれ

7.1　社内ツールと自動化が重要な理由

最大の無駄は作業に必要以上に時間がかかることではなく、待ちが発生すること

切り分けが難しいんですけど、これはほんとうにそうなんですよねー。このあとの記載もめっちゃわかりみがふかい。

7.2　なぜ組織はもっと自動化しないのか

自動化するための十分な時間など常にありません。

うちだけじゃなかった。エンジニアリングバックログに積んでいくのも大事だけど、この本はどちらかというと、「(よほど大変なもの以外は) 積む前に自動化しろ」という立場なのかな。積むと優先順位が低くて消化されないと。

7.3　自動化に関する文化の問題を解決する

7.3.2.1 手動と自動の間の妥協点

手動タスクの総量に限界を設定するのはすごく良さそう。

これ、なんでも適用できそうでよさそうですよね。テストでも、インフラでも、ログ収集でもなんでもつかえるなーみたいな。

7.3.3 手動作業のコスト

技術者は一般的に、トレードオフを財務の言葉に置き換えることが苦手です。

耳が痛い。でも、実作業時間を計測していれば、ほぼそのままコストになりそうな気もしますね。 (はやせ)

実績がない状態で見積をする話でした。

機会損失や，待ち時間， SLO にも影響する (きょんさん)

販管費なのか減価償却なのか．経営層に伝わる言葉にしないと承認されづらい．

7.4　自動化を優先する

7.5　自動化の目標を決める

業務の中で自動化を優先することは、自動化の文化を築くための唯一の方法

2分で終わるタスクを実施してもらうのに4時間待つということもあります。2分で済む質問をするために、4時間も待ちますか？　おそらくそんなことはしないでしょう。

一気にやりたいことが終わっていく快適さと、待ちがあるから保留にしなくてはならなくなるストレスの比較は、モブプログラミングの話でも聞いた。自動化で作業する人のストレスが減るだけでなく、そのタスクに関わる周囲の人も快適になれる話なんだなというのがわかりやすい数字。(98lerr)

必要な承認なのか？みたいなのもある。

そのタスク自体が承認されてるのに、タスクの都度実施承認をするというのは順番が違いそう。

チームに判断できる人がいないなら従前の承認フローは有効だが、チームに判断できるマネージャーがいるのに必要か？

しかし依頼を単に完了させるのに必要な最低限のことをするのではなく、プロセスの自動化に労力を割くタイミングをどのように判断すればよいのでしょうか？　これが、ほとんどの自動化の取り組みを妨げる要因となっています。

対応する枠や時間を決めていないと、他のタスクを優先して蔑ろになってしまうのは過去よくありました。強い意志を持った人が進めることで打破できることもあるのですが、問題あった時すぐ対応するのが一番結果につながりますね。(98lerr)

バックログに入れないで、すぐやろうというのはいい言葉と思いました。(98lerr)

「暇なんて、プロダクトに価値があるうちはずっと来ない」(はやせさん)

レトロスペクティブの延長で、マイスプリント2時間とか決めて自動化や改善のタイムボックスを入れるか？終わらなければ、プラニングで詰むとか。

自動化のチケットは、タスクを手動で実行した人の心にその苦痛が残っている間に着手するのが良いです。

↑の記述の一部ですが、「喉元過ぎれば」で次の仕事を始めると忘れちゃいますよね。(hayase)

タスクを定期的に実行するための良い解決策を思いつかない場合は、現時点ではそのタスクは自動化の良い候補ではないということです。

「能力がない」場合に、「良い候補でない」と判断するか「他のチームに頼る」を選ぶかは難しい。

あなたとあなたのチームメンバーが確実に学び続けるための計画が必要です。

整備するために、管理職の決裁がいると思うんですが、チームに権限を移譲してくれているものでしょうか。(hayase)

もし継続的な学習が仕事の一部だと言うのであれば（もしあなたが技術者で、こう言っていないのであれば頭を検査してもらいましょう）、それは勤務時間中に行われるべきです。

勤務時間中の定期的勉強会の時間を設けた結果の説明に悩む時もありましたが、こういったところも成果として言いやすいですね。ここがないと、属人的に得意な人がいるときしか自動化が進まなくなる場合がある。(98lerr)

こういった技術的負債の返済の中に、古いワークフローの自動化はあまり含まれません。うまく機能していないものに焦点が当てられ、単に非効率なものは話題に上らないのです。

「動いているからいいじゃないか」になりがちですよね。(hayase)

7.6　スキルセットのギャップを埋める

システムが変更される際、自動スクリプトはテスト対象と見なされない一方で、そのスクリプトが動かなくなるとそのシステムを使用するすべての人に大きな影響を与えることになります。

見なされないというだけでなく、存在が認識されていない場合もありますよね。 (hayase)

それを自動化することによってお互いの仕事がより快適になるのであれば、道のりはずっと簡単になります。これが当事者になるという考え方（skin-in-the-game concept）です。

skin-in-the-game (自らをゲームの中に入れる)というのが、当事者という言葉よりも入り込んでいくという感じがして、この元の言葉を残してくれてる訳がありがたい。(98lerr)

7.7　自動化のアプローチ

タスクにおける安全性とは、タスクが不正確に実行されたとしても危険な結果をもたらさないという考え方

スピード重視で作ったメモが残ってた時に、第三者が副作用を読み取って手順化する時の見落としが危ういと感じる時もあります。ある程度補足を残すか、忘れないうちに自動化まで持っていくかなどは必要かもしれないです。(98lerr)

困難なタスクを自動化する際には、基本的なアプローチでタスクを処理することが大切です。自動化に関しては、実行時の安全性を常に念頭に置いて設計する必要があります。

複雑な仕組みで自動化すると他の人がメンテナンスできないものになってしまう懸念があります。何をするにも同じと思いますが、困難なものほど基本的なアプローチでというのを自分たちに言い聞かせるのは大事ですね。(98lerr)

過去の人が作ったバッチ、テストもなく「動いてるうちは触れない」ものになりがち。

バッチ・自動化の全体のテストって，どう自動化すると良いのでしょうね．安全に二度実行できるようになっていれば動かせばいいんですが，どうしても副作用があって．

後半にタスクを分解してから困難さをランクづけするっていうのはいいなっておもった一方で、1-10は細かすぎないかなーって思ったりしました。が、大量に運用をやっているとそれくらいの精度で回答できたりするものなのかな。

7.8　本章のまとめ

みんなからのコメント

読んだ直後の感想話す時間が楽しい。35分開始でもう少し話す時間を広げるか？

それもいいかも！！！

実践する/伝えるためのハードルはなにか？

自動化を仕事の一部であり優先するっていうのをPOやマネージャーに理解してもらうこと

ツール選定の時点で自分がかかわっていないことで自動化しにくいうえでがんばらないといけない

IaCを触っている人が少ないとか？

自動化に向かないツールが自動化用に置かれた環境だと、それが邪魔になることも。

一緒に使うと良さそうなプラクティスやマインドセットはなにか？

工数の見える化？でも、アンチパターンっぽい気もする。。。

プランニングポーカー

ペアワーク

モブワーク（自動化に必要なスキル持った人を集めて一気に作る。集まらなくて作れない、にならなければ）

ハードルの乗り越え方はなにか？実践/伝える方法はなにか？

ペアワーク

プロジェクトが始まる前に安定稼働への費用対効果を見えるようにするとか

プロジェクトが始まってからだと予算がないってことがありえそう

テクノロジーがわかるPO？PdM？をたてる

っていうのが不要になるような説明テンプレスライドがコミュニティにあるといいんでしょうね。って改めて思いました。。。

スプリントレビューで手動タスクのスコアを確認する時間をもうける

どれくらい効果がありそうか？

最低限のことができる（改善するためのどだいがあるような予算はつくれる）